this feature of Applicant's independent claims is not shown or suggested in the 
Thomas reference. 

In the "Response to Arguments" section, the Office Action mischaracterizes 
the Thomas reference. The "location repository" is called meta-data and the "location 
of an object" is called the true-data attribute. The "location repository" is a data 
structure but does not indicate any information at all about the location of an object. 
What about the location of an object does the repository indicate? Does it indicate 
that the location is in a particular domain of a storage system? Does it indicate what 
users or group of users can access the location? It is believed that there is nothing 
about the "location repository" that describes anything about the locations of objects. 
In fact, the location repository contains a number of attributes, where each attribute 
describes the location of a particular object. 

Thomas describes a profile retrieval system that is used to customize an 
instance of a created object using data that is stored in various repositories. Each 
repository in Thomas has a number of entries where each entry includes what is 
referred to in the instant application as a "true-data attribute" Importantly, there is not 
a single instance in Thomas where meta-data is stored with or associated with the 
true-data attributes. The Office Action relies on the language at col. 3, lines 32-42 to 
show such an association. However, the "information identifying the storage location 
of an object" is an attribute of the object, not an example of meta-data. This is evident 
in Table 1 where this feature is illustrated. In table 1, each object is associated with a 
number of attributes such as data storage locations and accessor object brokers. There 
is no meta-data associated with these attributes. 

If we break table 1 down for analysis, the entry labeled "Object#l" is a header 
having a value that identifies a name or unique ID for a particular object. The next 
entry, labeled "Location#l", indicates a place where object#l is stored. Hence, 
Location#l is an attribute of object#l. The value contained in Location#l is not 
meta-data because it does not describe anything about the name of "object#l". What 
is missing from Thomas is any indication of meta-data that would describe something 
about the true-data contents of each entry. For example, if Table 1 included an entry 
that indicated the name "object#l" contains 18 characters, or the name of "object#l" 
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was accessible only to certain users, such an entry would be meta-data. Instead, each 
entry includes only an attribute of the object itself, not meta-data describing the true- 
value of the attribute. 

To be clear, what claim 1 , for example, calls for is a method in which each 
attribute in Table 1, such as each location number and each object broker, would have 
meta-data associated therewith. Thomas simply does not teach this type of 
information. 

The amendments to claims 1,18 and 41 call for the meta-data to be stored in 
the same profile object as the true-data. This is intended to avoid confusion over the 
distinction between storing data in various repositories that may be related somehow, 
as shown in Thomas, with creating an association in a single data structure between 
true-data and meta-data. 

Claims 2-17, 19-40, and 43-53 that depend from claims 1, 18 and 42, 
respectively, are believed to be allowable for at least the reasons set out above. 
Moreover, the Office Action consistently refers to portions of the Thomas reference 
that illustrate various attributes and equates them with the claimed meta-data values 
set out in the independent claims. The distinction between attributes and meta- 
data cannot be ignored, even if it is difficult to understand. Hence, each of the 
dependent claims is believed to be independently allowable because they call for 
specific meta-data values that are not shown or suggested in the relied on reference. 

B. Conclusion 

In view of all of the above claims 1-53 are believed to be allowable and the 
case in condition for allowance which action is respectfully requested. 

No fee is believed to be required by this response as determined on the 
accompanying transmittal letter. Should any other fee be required, please charge 
Deposit 50-1 123. Should any extension of time be required please consider this a 
petition therefore and charge the required fee to Deposit Account 50-1 123. Attached 
hereto is a marked-up version of the changes made to the specification and claims by 
the current amendment. The attached page is captioned " Version With Markings 
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Respectfully submitted, 



Date: September 27. 2001 



BY: '^a^^-a^ 

Stuart T. Langley #33,940^ 
HOGAN & HARTSON LLP 
One Tabor Center 
1200 17th Street, Suite 1500 
Denver, Colorado 80202 
Phone: (720) 406-5335 
Fax: (720) 406-5301 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 
A. In the claims 

1 (Twice Amended). A method for managing a profile service, the method 
comprising: 

storing at least one true-data attribute in a profile object, said true-data 
attribute includes a true- data key and at least one true-data value field; 

associating at least one meta-data attribute with said true-data attribute, said 
meta-data attribute includes a meta-data key and at least one meta-data value field, 
wherein the meta-data value field describes the associated true-data attribute; 

storing said associated meta-data attribute in said profile object ; and 

managing said true-data attribute according to said associated meta-data 
attribute. 

18(Twice Amended). A profiling service for accessing user data, said profiling 
service comprising: 

a plurality of profile objects; 

at least one true-data attribute contained in each of said profile objects, said 
true-data attribute includes a true-data key and at least one true-data value field; 

at least one meta-data attribute associated to said true-data attribute and 
contained in said profile object , said meta-data attribute includes a meta-data key and 
at least one meta-data value field, wherein the meta-data value field describes the 
associated true-data attribute; and 

methods within each profile object to access the user data according to said 
meta-data attribute. 

41 (Twice Amended). A profiling service for accessing user data, said profiling 
service comprising: 

means for storing at least one true-data attribute in a profile object, said true- 
data attribute includes a true-data key and at least one true-data value field; 
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means for associating at least one meta-data attribute with said true-data 
attribute, said meta-data attribute includes a meta-data key and at least one meta data 
value field, wherein the meta-data value field describes the associated true-data 
attribute; 

means for storing said associated meta-data attribute with said associated true- 
data attribute ; and 

means for managing said true-data attribute according to said associated meta- 
data attribute. 

42(Twice Amended). A profile object for maintaining client configuration data 
in a hierarchical fashion, the profile object comprising: 

at least one true-data attribute in the profile object, said true-data attribute 
includes a true-data key and at least one true-data value field; and 

at least one meta-data attribute associated to with said true-data attribute and 
stored in said profile object , said meta-data attribute includes a meta-data key and at 
least one meta-data value field, wherein the meta-data value field describes the 
associated true-data attribute. 
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